From igc.apc.org!notes Sun Nov 29 15:37:18 1992 From: arni@web.apc.org (Arni Mikelsons) Date: 24 Nov 92 13:22 PST Subject: - BIlling software To: Recipients of conference "tech.smallsys" Message-Id: <269400021%web.apc.org@igc.apc.org> Billing System Development The Global Networking Workshop agreed that there is an urgent need for a comprehensive but simple invoicing package for African host operators including ESAnet, NGOnet, Satellife and others. This package would also be useful for node operators in Asia and Latin America. The ability to charge efficiently and accurately for services is crucial for African hosts, many of whom are not willing to open their services to third parties until they can do this. Billing software is thus an essential element in developing better access to electronic hosts in Africa and elsewhere. Based on the experience of APC nodes, this kind of accounting is very specialised, a specific package should be written for this. The thousands of existing FIDO hosts usually use a much simpler method of charging than we require, if they charge anything at all, so there is nothing in the general FIDO world that could be adapted for this purpose. A few existing hosts have already developed their own billing systems, but they are unlikely to be universally applicable, well documented or supported, or up to the specification that we require. Existing programmes will undoubtedly provide useful ideas and experience in writing a comprehensive package. A survey and analysis of what already exists will be part of the work. The billing system will import data generated by the host system and create invoices on a regular basis (eg. monthly), track payments, issue statements as required, and produce reports and summaries to enable the package to be integrated with other accounting systems. The Billing Software is not a full 'accounting package' but an invoicing and accounts receivable programme. The billing software will be designed for any host with up to 300 users, not just Fido hosts provided the host can generate usage data. Hosts with more than 300 users, may want to consider upgrading to a more sophisticated system. The billing software will be part of the host upgrade of Easy Link to FIDO, and as such, free to third world users. It will be written in a commonly used language or application (such as dBase). Assumptions 1. In the current standard Fido addressing scheme, where each user is considered a "point", point addresses should be used as account references. 2. Each point on a node is a sales account and will be billed separately. 3. Messages originating from other nodes should be billed to the node of origin, rather than a point. Functionality 1. Import of Data Files Should Import any form of ascii, delimited file containing billing data. Several standard formats would be included (MsgTrack, APC fax and gateway data), as well as the facility to allow the operator to describe a new text file. See below for detailed specification. 2. Error trapping When a message is detected that was originated by an unknown point or node, it will generate a warning and open an 'account'. When it receives record of a charge about which it has no charge information, it will generate an error and allow the operator to create or modify charge information on the spot. 3. Look up and maintain account information Besides the address fields for each user/account/point/node, each record will also contain: i) a 'user group' which will determine the rate at which they are billed; ii) the 'currency' in which they will be billed (which may be pure bytes of traffic); iii) a byte credit -- e.g. the first 10k (or 0) bytes not be billed. (This could, alternatively, be an attribute of the user group); iv) an optional subscription, which may be 0.00; v) search accessibility by name and by point address; vi) fields that allow any combination of charge categories to be discounted to less than 100% of their usual value, or 'marked up' by specifying a percentage greater than 100%. The operator will be able to view or edit the above information. When viewing, the operator will also be able to see: i) current balance of the account; ii) transaction history for at least the current financial year. 4. Enter payments or credits received This sub-system should allow entry of payments and entry of manual credits to correct errors in billing. Payment(s) information should include: account reference (username or point number) payee name payment date date received payment amount currency payment type (check; cash; credit card; correction; other credit) reference number (bank & check #; credit approval; other info) 5. Enter zone information Usage 'charges' should be made according to the ultimate destination of the message in at least 10 rate codes: - Local -- on the same node; - A,B,C,...: -- specific zones, regions, or nodes can be assigned a rate code and may use 'wildcards' All other destinations/services where the rate = cost. This is used for fax and APC gateway charges that are supplied ready- calculated, for example. If possible, there should be flexibility to add additional destinations and types of message traffic beyond 10. Consideration of taxation requirements (which may vary from item to item) may also be necessary for inclusion into charge records. For example, a user manual may be exempt from sales tax, users outside the node's own country may be exempt, there may be more than one type/rate of sales tax to be applied, as in Canada. 6. Reports All reports will be output to disk in a format which can be imported directly into Lotus 1-2-3 (TM) and other spreadsheets and programs, and will optionally be printed immediately. The minimum reports required for accounting purposes are: i) account history and balance for one account or for a wildcard- defined group of accounts; ii) monthly use ('billing') summary; iii) monthly cash-flow summary if appropriate; iv) aged debtors: how much owed that's 1,2..12 months old, or older. v) charges to users sub-totalled by charge band to compare with host bills for various services (the phone bill; APC gateway charges). 7. Invoices The system will produce operator-configurable invoices. Fields available on the invoice form will be: - header information of node operator: Node name, address, instructions for remitting payments; - paper size and orientation number of invoices to print per page; - user name and Address - system identifier - invoice date - period of charges - total amount due - current charges - past-due charges - date and amount of most recent payment - all details (may be omitted) - sub-totals for each charge band (may be omitted by operator) 8. Miscellaneous system settings These will include the host operator's node, charge band information, currency names and conversions, simple tax rates, user-group information, etc... 9.Processing One of the following routes will be chosen: - updating of transaction history and user balances should be separated from invoice processing so that invoices can be completely printed and reviewed by the operator before transactions are recorded and balances updated; - a system with easy invoice deletion or re-issue for corrections. It should reissue with a different number and new date usually, so that invoice numbering still stays in chronological order. This requires that the system keeps track of whether a particular month/user has been issued or not. Deleting an invoice should be accompanied by a warning not to do this unless you have the copy of the invoice in your hands and are about to destroy it. 10. Coping with hyper-inflation. There will be a facility to run regularly which will adjust all past due balances in a particular currency by a percentage to compensate for inflation. This can work in the form of a set (configurable) percentage per month 'charge' on overdue amounts. It will normally be a monthly routine, to be run just before the next invoicing, but can be adjusted to run more often if necessary. The percentage is an attribute of the currency, and can be set for each currency in use. 11. Year-end functions To produce annual reports, close off data files and bring forward opening balances for the new year. The previous year should still be accessible (will be needed for copy invoices and statements, etc.) We should investigate with the likely volumes we are designing this for whether annual closing is enough, or whether it should be (optionally) more frequent to keep the data files to a reasonable size. Suggest storing different years/months in different sub-directories to facilitate manual archiving by compressing or removing from the hard disk of older data. This will also make it relatively simple to ask the system to let you view older data. There should be constraints on editing or changing data other than the current set. General system features. It will use a menu-driven interface: i) on-line context-sensitive help available at all times by pressing the same key, producing assistance relevant to the current task and pointers to 'further reading'; ii) all fields which require input of a code (for example, user group) are marked, and a picking-list of possibilities with descriptions is displayed; iii) all input is checked: undefined codes, invalid dates and improper numbers are rejected with an explanation; iv) all menus and user input forms are stored in a separate file, simplifying the process of producing versions in several languages; v) password control is optional; vi) users may quit from any point. The level of system "fussiness" (as in "Are you sure you want to...)" is definable; if passwords are implemented, each user may set their own level of "fussiness". Specification of Data File Importation i) should be a sub-menu off the main system menu ii) should contain pre-defined input formats for: - MsgTrack - APC fax and gateway data iii) should provide for operator defined new formats. The process could be: - display first 10 lines of new data file; - ask operator which delimiter should be used; -find records with same number of fields that constitute more than about 80% of the file; -display a sample record of this format; - starting with the first field, ask the operator to match it with a field required for entry. A list of fields required by the system should be displayed. Data types should be checked automatically, and inconsistencies reported to the operator; - the operator should be able to save and name this new input format for future use. iv) should provide testing of data file consistency and integrity the system should examine any data file and report to the operator: - total number of records; - number of records not matching the format; - list either total bad records or unique bad records for operator inspection; - allow operator to proceed with processing, and ignore the bad records, or cancel processing. v) all account, transaction history and invoice detail information will be in dBase-compatible .DBF files. vi) the host software should have a key configured for exiting into the billing system to facilitate quick checks on the status of any account.